home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 3871 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.4 KB  |  146 lines
  1. Newsgroups: comp.sys.amiga.misc
  2. Path: in1.uu.net!xenitec!focsys!wayne
  3. From: wayne@focus-systems.on.ca (Wayne Fisher)
  4. Subject: Re: OS features
  5. Message-ID: <DM4Etu.49K@focus-systems.on.ca>
  6. Organization: Focus Automation Systems Inc.
  7. References: <4aj1tc$39r@candelo.dpie.gov.au> <1058.6591T492T1743@cycor.ca> <DLnqBB.DuD@focus-systems.on.ca> <4e442t$4ve@serpens.rhein.de>
  8. Date: Thu, 1 Feb 1996 23:34:42 GMT
  9.  
  10. In article <4e442t$4ve@serpens.rhein.de>,
  11. Michael van Elst <mlelstv@serpens.rhein.de> wrote:
  12. >wayne@focus-systems.on.ca (Wayne Fisher) writes:
  13. >
  14. >>I don't understan this line of thinking. With a MMU, you can add
  15. >>memory protection and virtual memory (not including paging to disk)
  16. >>with a minimal amount of overhead to the system.
  17. >No, you can't.
  18.  
  19. My opinion is that it can be done.
  20.  
  21. >>We're only talking
  22. >>single digit percentages here.
  23. >We are talking 10-100% depending on the system function.
  24.  
  25. I wouldn't expect this. I would expect that most system calls would be
  26. hit with less than 10% overhead with a few at more than that. IMHO,
  27. average would be less than 10%.
  28.  
  29. I'll admit that I haven't done any large programs under AmigaOS but I
  30. can't see why the overhead would be an order of magnitude more than
  31. most other OSs.
  32.  
  33. The machine I use at work is a fully protected OS running on
  34. 80[345]86s. It supports virtual memory but doesn't page to disk. It's
  35. realtime and has incredible context switch times. Overhead from memory
  36. protection cannot be very high.
  37.  
  38. >>although that is a natural extension to it. By virtual memory, I mean
  39. >>giving all programs a contiguous address space independant of other
  40. >>programs.
  41. >This breaks 99% of all programs.
  42.  
  43. Maybe if you include games but they break on almost any machine that
  44. is capable of memory protection anyways.
  45.  
  46. And if this was true, I doubt that GigaMem would exist. Nor would it
  47. work with a number of large commercial applications.
  48.  
  49. >>Neither of these features affects the realtime nature of the machine.
  50. >You bet... It affects speed.
  51.  
  52. What does speed have to do with realtime. Faster just means you can do
  53. more in the same amount of time - it isn't a requirement for realtime.
  54.  
  55. >>    - protect code from writes.
  56. >That's no problem.
  57.  
  58. >>    - protect unallocated memory from any accesses.
  59. >MMU granularity forbids this. You cannot trap accesses to partially
  60. >allocated pages.
  61.  
  62. Memory would be allocated to program on a page basis. Sure, you can't
  63. protect the memory that malloc() hasn't used yet but you can catch
  64. stray accesses to that 8MB chunk that doesn't belong to anyone.
  65.  
  66. >>    - protect any ROMs from writes.
  67. >That's code and hardly matters. But protecting all the I/O addresses
  68. >would help.
  69.  
  70. Well, it matters if the OS is going to catch it or not.
  71.  
  72. >>    - new programs' code and data would be protected from access by another
  73. >>      process unless explicitly allowed by the program.
  74. >Kills close to all system functions. You had to write a completely new
  75. >AmigaOS.
  76.  
  77. Remember, OS code can be 'priviledged' and access everyone's data. The
  78. biggest thing as far as programs go is in passing messages between
  79. each other.
  80.  
  81. And yes, there would have to be some work done on AmigaOS to handle
  82. access to program data.
  83.  
  84. >>    - option to kill offending process or simply log the offence.
  85. >Pretty difficult. It requires some conventions on how to allocate resources.
  86.  
  87. At first, it could operate similar to the "suspend" operation of the
  88. software failure requestor. It could return memory that was private
  89. and leave it at that. Anything allocated as shared would have to
  90. remain around.
  91.  
  92. Later OS revisions could expand on this and on what memory is
  93. protected and how.
  94.  
  95. >>"much more"? I don't think a few percentages is "much more".
  96. >
  97. >You forget that memory protection is nothing if you cannot protect
  98. >the system from invalid parameters to system functions. Most system
  99. >functions however use shared data structures.
  100.  
  101. Invalid parameters is different from memory protection, at least IMO. 
  102. What does memory protection have to do with passing a value of 1111 to
  103. a function that expects something in the range 0-255?
  104.  
  105. Either force shared data to be explicitly allocated by the program as
  106. shared to work out a way to let the OS do it. No question, some though
  107. and work would be required here.
  108.  
  109. >>And I
  110. >>don't see how it's going to change the whole concept of the Amiga.
  111. >
  112. >Close to everything in the system would have to be changed from using
  113. >shared data to anonymous handles. Each handle has to be checked for
  114. >validity.
  115. >
  116. >The whole concept of device drivers had to be changed.
  117. >BOOPSI is dead.
  118. >System hooks are dead.
  119.  
  120. I'll admit that I'm not familiar with this area of the OS. However,
  121. device drivers could become a priviledged part of the OS when they are
  122. activated.
  123.  
  124. >>It
  125. >>just means that you can't pass pointers between processes and the
  126. >>machine becomes more stable.
  127. >
  128. >Unfortunately most parameters are passed by pointers. You do have
  129. >to change everything.
  130.  
  131. No change as far as the function prototypes of the API are concerned.
  132.  
  133. Remember, I'm not asking for it all at once. Start with the "easy"
  134. stuff and work up from there. We might not be able to plug all the
  135. holes but maybe we can get all those below the water line.
  136.  
  137. >                                Michael van Elst
  138.  
  139. Wayne
  140.  
  141. -- 
  142. Wayne Fisher, Software Engineer           | Focus Automation Systems, Inc.,
  143. wayne@focus-systems.on.ca                 | 3-554 Parkside Drive,
  144. #include <stdDisclaimer.h>                | Waterloo, Ontario. N2L 5Z4
  145. We engineer innovative imaging solutions. | (519) 746-4918
  146.